home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1055 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.3 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: lars.farm@nts.mh.se (Lars Farm)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: sample auto_ptr template
  5. Date: 12 Apr 1996 08:53:43 PDT
  6. Organization: pv
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <AD9409799668E161@sleipner.nts.mh.se>
  9. References: <009A04DA6A831C40.49800EAC@ittpub.nl>  <bill-0504961003150001@bgibbons.vip.best.com> <4k4noe$igl@jabba.lehman.com>  <bill-0804960932250001@bgibbons.vip.best.com> <4kcr2d$p03@jabba.lehman.com> <KANZE.96Apr10111407@gabi.gabi-soft.fr>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. Content-Type: text/plain; charset=iso-8859-1
  12. Content-Transfer-Encoding: 8bit
  13. X-Original-Date: Fri, 12 Apr 1996 13:22:01 +0200
  14. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  15.     iQBVAwUBMW58iEy4NqrwXLNJAQEQDwIAzaJb+tInP/XHgDpMHdkY7YjTAKKxKz+k
  16.     J37umZG3oGmGc3ReHNq5R5TSg1Loo1YHKGNWNhvdlHPwrnNk0qHpqQ==
  17.     =lO2z
  18. Originator: austern@isolde.mti.sgi.com
  19.  
  20. In article <KANZE.96Apr10111407@gabi.gabi-soft.fr>,
  21. kanze@gabi-soft.fr (J. Kanze) wrote:
  22.  
  23. >I believe that John Skaller had a proposal with something like six
  24. >different pointer types.  The committee found this a little too
  25.  
  26. He said a while ago that he proposed two classes(*). (1) auto_ptr for
  27. lifetime control within a block (no copy/assign) and (2) a ref counted
  28. class for shared objects. There is a need for both but only one was
  29. accepted and that is the real problem.
  30.  
  31. auto_ptr<> is slowly being mutated into a mixture of the two classes. It
  32. has moved away from its original goal and is becoming a cheap shared_ptr<>.
  33. This requires very strange and disturbing use of op=/copy.
  34.  
  35. void f( auto_ptr<X> x ) { ...will delete x }
  36.  
  37.   // promise: x const, x will _not_ change, x will _not_ become invalid
  38. void g( const auto_ptr<X>&x ) {
  39.   // ... x ok
  40.   f(x);
  41.   // ... oops
  42. }
  43. void h() {
  44.    auto_ptr<X> p( new X );
  45.    // p valid
  46.    g(x);
  47.    // p bad. Undetected by the compiler because the standard 
  48.    // library class auto_ptr subverted the C++ type system
  49. }
  50.  
  51. IMHO the only reasonable solution is to have two classes. If the committee
  52. only accepts one then users will have to write the other. That's ok, as
  53. long as it is obvious that auto_ptr isn't a general purpose smart_ptr. With
  54. the current weird auto_ptr copy/op= perhaps users will have to write both
  55. the original and the ref counted class on their own. Or worse, they will
  56. actually use auto_ptr as if it was the rejected ref_counted ptr. This is a
  57. reasonable assumption because auto_ptr is the only standard smart ptr and
  58. users should be allowed to assume it is safe. It would be safe with private
  59. op=/copy as the original.
  60.  
  61. When designing a class for mass consumption it should not only support the
  62. intended idioms. It should also prevent missuse in common situations. The
  63. original does that. The current auto_ptr doesn't.
  64.  
  65. Please reconsider John Max Skallers original proposal.
  66.  
  67. (*) he has also mentioned other smart pointers here. holding arrays -
  68. block/ref-counted. copying pointers and cloning pointers using varying
  69. implementation techniques but AFAIK they were never proposed as standard
  70. classes.
  71.  
  72. --
  73. Lars Farm, lars.farm@nts.mh.se
  74. ---
  75. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  76.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  77.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  78.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  79.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  80. ]
  81.